The nature of the horizontal microcode (HMC) used in modern, highly complex and highly parallel data processors, such as the IBM Application System/400, is such that not all combinations of control word field encodes result in a meaningful control word. Thus, in order to be valid, each microcode instruction must satisfy a set of restrictions including, but not limited to, those imposed by the design of the processor. These restrictions can arise due to the architecture of the processor, for example they can be restrictions on data movement, even if only to prevent bus clashes. In addition, ad hoc restrictions can be introduced during design of the processor to circumvent hardware problems or to enable certain hardware optimizations to be made. The restrictions could also be imposed by, for example, requirements that the microcode meet certain coding standards or conventions.
The efficient checking of restrictions against a set of microcode instructions is a significant problem. The set of restrictions is generally very large and can change frequently, particularly during development of a processor.
Conventionally, a hand-written checking program is used to check the microcode against the restriction set. This checking program, when executed on a computer, accepts a representation of a microcode instruction or control word and generates a list of those restrictions, if any, which are violated by the instruction.
However, each time the restriction set is changed the checking program must be modified to reflect these changes. Modification of the checking program is generally a laborious and time consuming process because usually the information embedded in such a program is too implicit to be reused or modified in an effective manner. If development of the microcode is taking place in parallel with development of the processor, as is usually the case, it can introduce a significant delay in the processor reaching the market.